Apparatus and method for simulcast over a variable bandwidth channel

ABSTRACT

The present principles provide a method for a personalized mobile broadcast service operator (Service provider) to send content in the form of files with different compression formats in a variable bandwidth channel to one or more users who have access to the same service. Operators providing mobile broadcasts have the option of using residual bandwidth to provide these services. In such services, depending on the amount of bandwidth available for a mobile broadcast, a scheduler can choose to broadcast file content with higher compressed parameters thereby reducing the network footprint of the content file during lower bandwidth situations. A lower compressed format of the same content could then be potentially scheduled to broadcast at a later time when more bandwidth becomes available eventually replacing the highly compressed copy which was received earlier on the client.

BACKGROUND

1. Technical Field

The following principles of the present invention relate to datatransmission. More particularly, they relate to the transmission ofsimulcast data over a variable bandwidth channel.

2. Description of Related Art

Content services are provided by a spectrum of different suppliers. Forexample, residential digital video services may include digitaltelevision, Video on Demand (VOD), Internet video streaming, etc., eachservice typically providing audio-video data displayable at differentencoded levels.

Content data is transmitted in a bitstream, or a continuous sequence ofbinary bits used to digitally represent compressed multimedia, e.g.,video, audio, data. The bitstream is transmitted over a transmissionchannel. When content data is sent as a continuous bitstream, a clientdevice buffers this stream and offers a real time playback of the same.

Mobile broadcast networks are challenging environments in which todeliver audio/video content. The bandwidth available over a connectionat any particular instant varies with both time and location. Thisvariation in bandwidth causes entire packets containing substantialaudio/video content to be lost. In addition, the latency through thenetwork, causing the video that is ultimately displayed to ‘jitter’ orlose clarity at the client. These factors may be tolerable for filetransfer traffic where jitter does not matter since high level protocolscorrect for errors and losses.

In streaming real time live content live broadcast networks, methodsalready exist where transmission of audio-video content varies as afunction of available network bandwidth. Depending on the bandwidthavailable, the head end or transmitter side of the service is able toeither buffer data to send them at a different time or at real time,using an encoder to vary the content stream's compression parameters sothat it can be transmitted at current available bandwidth.

Operators providing live televised services, stream in real-time, alower quality version of a televised broadcast feed to its mobilecustomers. For example mobile operators like Verizon and Sprint providelive TV services, e.g., VCast Live TV, MobiTV, etc., at a reducedresolution and bitrates to mobile handsets using their services.

SUMMARY

According to an aspect of the present principles, the method forproviding data over a network of devices includes establishing abandwidth value for providing a data over a communication channel,providing the bandwidth value to a client device over the communicationchannel, and providing a predetermined version of the data over thecommunication channel to the client device in response to a comparisonof the established bandwidth value with a bandwidth threshold. Providingdata may include transmitting data via a wireless connection orproviding data via a wired connection.

According to another aspect, the bandwidth can be established byestimating the available bandwidth, or could be established by settingan initial value of the bandwidth.

A bandwidth threshold is set based on the established threshold, andaccording to one implementation, the bandwidth threshold can be set asone half the established bandwidth value.

In accordance with another aspect, a low compression version of the datais transmitted when the bandwidth is higher than the bandwidththreshold, and a high compression version of the data is transmittedwhen the bandwidth is lower than the bandwidth threshold.

According to another implementation, the apparatus includes a head endscheduler configured to establish a bandwidth value for transmittingdata over a communication channel, transmit the established bandwidthvalue to a client device, and transmit a predetermined version of thedata in response to a comparison between the established bandwidth valueand a bandwidth threshold.

According to a further implementation, the present principles areembodied in a computer program product having a computer useable mediumhaving computer readable program code embodied thereon for use incommunicating data over a communication channel. The computer programproduct includes program code for establishing a bandwidth value fortransmitting the data over the communication channel, program code fortransmitting the established bandwidth value to a client device over thecommunication channel, and program code for transmitting a predeterminedversion of the data over the communication channel to the client devicein response to a comparison between the established bandwidth value anda bandwidth threshold.

Other aspects and features of the present principles will becomeapparent from the following detailed description considered inconjunction with the accompanying drawings. It is to be understood,however, that the drawings are designed solely for purposes ofillustration and not as a definition of the limits of the presentprinciples, for which reference should be made to the appended claims.It should be further understood that the drawings are not necessarilydrawn to scale and that, unless otherwise indicated, they are merelyintended to conceptually illustrate the structures and proceduresdescribed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings wherein like reference numerals denote similarcomponents throughout the views:

FIG. 1 is block diagram of a typical broadcast network adapted formobile broadcast;

FIG. 2 is a block diagram of an exemplary personalized content broadcastsystem;

FIG. 3 a is a block diagram of the method according to an implementationof the present principles;

FIG. 3 b is a flow diagram of the method according to an implementationof the present principles; and

FIG. 4 is a flow diagram of the method according to anotherimplementation of the present principles.

DETAILED DESCRIPTION

FIG. 1 shows a typical broadcast network system 100 adapted for mobilebroadcast. The original content signal 102 is sent through a contenttranscoder 108 which compresses the audio-video content fit fortransmission (110) over a mobile network 111 to a mobile client 112. Inan on-demand device (e.g., Verizon Vcast service), users are allowed tostream multimedia files to their respective devices. In these services,the server sends out a transcoded version of the content, with thebandwidth of the transcoded version determined so as to not exceed thebandwidth offered to the user over a unicast channel when it isrequested by the user. With networked streaming of video or othermultimedia, the instantaneous bandwidth of the compressed video at anypoint in time is limited to the available network bandwidth, within thebounds of a buffer at the client, in order to maintain continuous videoplayback. If the instantaneous bandwidth exceeds the availablebandwidth, playback at the client is disrupted.

When compressed multimedia is transmitted as files, rather thanstreamed, the bandwidth of the compressed multimedia does not need to bematched to the network bandwidth. The transmission time for themultimedia file does not need to correspond to the duration of thecontent of the multimedia file.

On-demand services consume bandwidth for each individual user, which isusually a very costly operation since it does not scale very well forlarge number of subscribers to the service. Although these practicesbring down the bandwidth consumption, in most cases it need notnecessarily be optimal for network and client device operations.

FIG. 2 shows a block diagram of a personalized broadcast video system200, which provides simple user interface for personalization, whileefficiently using network bandwidth and minimizing receiver batterydevice usage. The system 200 includes a head end 200, a broadcastnetwork 210 and a receiver 240. The head end includes an input clip 202,a scheduler 204, an electronic service guide (ESG) generator 206 and aFLUTE server 208. The receiver includes a FLUTE receiver 212, and ESGparser 214, a content selection control 218, a user profile 216, acontent storage device 220, and an audio/video player 222.

The user profile 216 on the receiver device 240 indicates the interestsof the user. Individual clips 202 to be broadcast are associated withflexible metadata tags, such as keywords, are sent to the ESG generator206 through the scheduler 204. When content, particularly videoprograms, is broadcast, the receiver device 240 selects individualprograms to record based upon calculating a score corresponding to theprogram. The score is calculated for a particular piece of content usingthe ESG content keywords and the user's profile, which indicates auser's level of interest in particular keywords. The user's profile 216can adapt based upon the user's viewing activity.

In an opportunistic bandwidth environment (i.e., Variable Bit Rate), theoutput channel bandwidth is not constant. This affects all the broadcasttiming calculations for each content file done by the scheduler 204.Hence, to provide a reliable schedule of broadcast, the scheduler 204needs to schedule broadcast of content files in a timely manner, basedon available bandwidth and its own estimates of available bandwidth.

The scheduler 204 periodically outputs a schedule for content filebroadcasts. This schedule is in the form of an ESG is communicated to aclient device. In a unidirectional broadcast environment, the receiver240 depends heavily on the schedule and meta-data information it getsfor selective reception of the content. It is important that the clientreceive the schedule in advance of the actual broadcast time. Theschedule broadcast by the server 208 contains meta-data information suchas broadcast times for each content. The broadcast timing information isimportant to the client, since a client can use this information toselectively switch on and off its receiver components based on thebroadcast times of different content, and hence make selective receptionof content viable. Also, since the client is switching its receivercomponents on only when needed, there is efficient user of the client'spower resources.

The scheduler 204 has a transmission monitor system (not shown) whichcontrols the transmission of content files according to the schedule.The transmission monitor system updates the scheduler 204 withtransmission status of each clip and variations in output channel speed.

According to the present invention, users of broadcast content services,such as those using the above-described systems, may receive contentwith varying compression formats depending on the bandwidth at the timethe content was scheduled to be broadcast. In such systems, the contentfiles are also scheduled to be re-broadcast as decided by the scheduler.If during the re-broadcast the amount of bandwidth is sufficiently high,then the scheduler may choose to broadcast a higher quality format ofthe content file.

By way of example, consider an audiovisual content Clip A is transcodedinto two different compression formats, ClipA_lowComp andClipA_highComp, with higher and lower bandwidth usages, respectively.The operator provides a number of live television services thatgenerally use up most of the available bandwidth.

Referring to the exemplary implementation shown in FIG. 3 a, there isshown the method 275 according to an implementation of the presentprinciples. Initially, the bandwidth of a communication channel isestablished (280). Those of skill in the art will recognize that thereare many different methods for establishing the bandwidth of acommunication channel. It is to be understood that the presentprinciples can be applied using any suitable method for establishing thebandwidth of the channel. Once established, the bandwidth information istransmitted (282) to the client device over the communication channel.At this point, a version of the data is transmitted (284) over thecommunication channel in response to a comparison between theestablished bandwidth and a bandwidth threshold.

FIG. 3 b shows the method 300 according to an implementation of thepresent principles. Initially, the scheduler 204 processes its databaseof content files and decides to output a schedule based on currentestimates of bandwidth (302). The schedule is then transmitted (304) toa client device 240. The client device now has an estimate of the timeswhen each content file is going to be broadcast. Based on thisinformation, the client can optimize its receiver routines.

Before the broadcast of each file, the scheduler 204 of the service canbe configured with an initial value of the bandwidth, or can beconfigured to make an estimate of the available bandwidth (302).

According to one implementation, the bandwidth thresholds can beestablished as being half of the initial value or estimated value of thebandwidth. If at the beginning, the bandwidth threshold is at a highvalue, BW_HIGH, the scheduler 204 would choose to broadcastClipA_lowComp which is of lower compression and hence higher quality butwith more bandwidth usage. If during some time elapse, the bandwidthallocated to the service changes, the schedule would be affected. Thescheduler would normally detect this through its transmission controlmodule. For example, if the bandwidth of the channel now fell to a lowerthreshold value, BW_LOW, the scheduler detects that change in thebandwidth, which now affects the schedule of its content filebroadcasts. This is the example shown in FIG. 3.

The scheduler 204, instead of re-scheduling all of its content files,will now choose to broadcast ClipA_highComp (308), which is highlycompressed version of the content file whose quality and bandwidth usagemay be lower but acceptable to the user. If the bandwidth at a laterpoint of time increases to a value BW_HIGH, and content file Clip A isscheduled for a re-broadcast, then this time around the schedulerchanges the threshold in the decision block 306 and would choose tobroadcast Clip A_lowComp (310) and the client on receiving this contentcould potentially detect this as a higher quality version of a previousfile and choose to replace the lower quality content file,ClipA_highComp.

The scheduler 204 chooses the version of the file to be broadcast sothat it would still maintain the timeliness of its schedule. The client,hence, sees no change in the schedule although there was a change in thebandwidth that was allocated to the service. In this manner, the clientdevice sees a seamless operation of the service.

FIG. 3 shows the example where the threshold determination of decisionblock 306 is BW_LOW. Those of ordinary skill will recognize thatchanging the threshold from BW_LOW to BW_HIGH will reverse the “yes” and“no” decisions of the shown implementation. This is shown, by way ofexample, in the flowchart of FIG. 4. Here, the steps 402, 404, 406 allcorrespond to the same steps 302, 304, 306, respectively. When thebandwidth threshold is above BW_HIGH, (otherwise, a “no” determination),the A_highComp clip is transmitted 408. When the bandwidth threshold isbelow BW_HIGH, the A_lowComp clip is transmitted 410.

It is to be understood that the present principles may be implemented invarious forms of hardware, software, firmware, special purposeprocessors, or a combination thereof. Preferably, the present principlesmay be implemented as a combination of hardware and software. Moreover,the software is preferably implemented as an application programtangibly embodied on a program storage device. The application programmay be uploaded to, and executed by, a machine comprising any suitablearchitecture. Preferably, the machine is implemented on a computerplatform having hardware such as one or more central processing units(CPU), a random access memory (RAM), and input/output (I/O)interface(s). The computer platform also includes an operating systemand microinstruction code. The various processes and functions describedherein may either be part of the microinstruction code or part of theapplication program (or a combination thereof) that is executed via theoperating system. In addition, various other peripheral devices may beconnected to the computer platform such as an additional data storagedevice and a printing device.

It is to be further understood that, because some of the constituentsystem components and method steps depicted in the accompanying Figuresare preferably implemented in software, the actual connections betweenthe system components (or the process steps) may differ depending uponthe manner in which the present principles is programmed. Given theteachings herein, one of ordinary skill in the related art will be ableto contemplate these and similar implementations or configurations ofthe present principles.

1. A method for providing data over a network comprising the steps of:establishing a bandwidth value for providing a data over a communicationchannel; providing the bandwidth value to a client device over thecommunication channel; providing a version of the data over thecommunication channel to the client device in response to a comparisonof the bandwidth value with a threshold.
 2. The method of claim 1,wherein the establishing comprises estimating (302) the availablebandwidth in the communication channel.
 3. The method of claim 1,wherein said establishing comprises setting an initial value for thebandwidth.
 4. The method of claim 1, further comprising setting thethreshold based on the established bandwidth value.
 5. The method ofclaim 4, wherein the threshold is set as one half the establishedbandwidth value.
 6. The method of claim 4, wherein the providing furthercomprises transmitting a low compression version of the data when thebandwidth value is higher than the threshold.
 7. The method of claim 4,wherein the providing further comprises transmitting a high compressionversion of the data when the bandwidth value is lower than thethreshold.
 8. An apparatus comprising: a head end scheduler configuredto establish a bandwidth value for providing data over a communicationchannel, provide the bandwidth value to a client device, and provide aversion of the data in response to a comparison between the bandwidthvalue and a threshold
 9. The apparatus of claim 8, wherein the scheduleris configured with an initial bandwidth value.
 10. The apparatus ofclaim 8, wherein the scheduler is configured to estimate the bandwidthof the communication channel to establish the bandwidth value.
 11. Theapparatus of claim 8, wherein the scheduler establishes the thresholdbased on half the bandwidth value.
 12. The apparatus of claim 11,wherein the scheduler provides a low compression version of the datawhen the bandwidth value is higher than the threshold.
 13. The apparatusof claim 11, wherein the scheduler provides a high compression versionof the data when the bandwidth value is lower than the threshold.
 14. Anapparatus comprising: program code for establishing a bandwidth valuefor providing data over a communication channel; program code forproviding the bandwidth value to a client device over the communicationchannel; and program code for providing a version of the data over thecommunication channel to the client device in response to a comparisonbetween the established bandwidth value and a threshold.
 15. Theapparatus of claim 14, further comprising program code for setting thethreshold based on the established bandwidth.
 16. The apparatus of claim14, wherein the program code for establishing a bandwidth value furthercomprises program code for estimating the available bandwidth of thecommunication channel.
 17. The apparatus of claim 15, further comprisingprogram code for setting the threshold as one half the establishedbandwidth.
 18. The apparatus of claim 15, further comprising programcode for providing a low compression version of the data when thebandwidth is higher than the threshold.
 19. The apparatus of claim 15,further comprising program code for providing a high compression versionof the data when the bandwidth is lower than the threshold.